The protocol for delivery of e-mail over the Internet is the Simple Mail Transport Protocol (SMTP). The specifics for these types of communications—as with other Internet protocols—are established through a Request For Comment [RFC] procedure, where the applicable RFC number for normal e-mail communications today is RFC-821, which essentially establishes the de facto protocols by which servers and clients send e-mail communications “in the clear” or unencrypted over the Internet. In many cases, these unencrypted communications go through one or more routers that are not controlled or trusted by either the sender or recipient of e-mail. Such an untrusted router might allow a third party to monitor or alter the communications between the server and clients, thereby compromising security.
There is often a desire, therefore, for two SMTP agents to be able to authenticate each other's identity. For example, a secure SMTP server might only allow communications from other SMTP agents it knows, or it might act differently for messages received from an agent it knows than from one it doesn't know.
Encryption is becoming increasingly important to corporate users, particularly in industries that regularly exchange confidential information via the Internet, such as health care, legal and financial services. Transport Layer Security (“TLS”) is an encryption standard designed to secure data where it is most vulnerable, in transit over the public Internet. As its name implies, TLS operates at the OSI (Open Systems Interconnect) Transport Layer. Operating at the transport layer, the standard is accordingly independent of the application protocol, and provides server authentication with optional client authentication.
The TLS encryption standard uses a key exchange protocol, such as an RSA (Rivest-Shamir-Adleman) asymmetric key system to establish a transport layer session. Another example of a key exchange protocol found in conventional systems is the Diffie-Hellman protocol. Upon establishing the transport layer session, the standard thereafter uses symmetric key encryption techniques, such as, for example, the IDEA (International Data Encryption Algorithm), DES (Data Encryptions Standard), and 3DES (Triple-DES) standards.
The TLS protocol exchanges records, and each record can be optionally compressed, encrypted and packed with a Message Authentication Code (MAC). Each record has a content_type field that specifies which upper level protocol is being used. When the connection starts, the record level encapsulates another protocol, the handshake protocol, which has content_type 22. The client sends and receives several handshake structures to and from the server. The client sends a “ClientHello” message, specifying the list of cipher suites, compression methods, and the highest protocol version it supports. The client also sends random bytes, which will be used later. The server then returns a “ServerHello,” in which it selects the connection parameters from among the choices offered by the client. Once these connection parameters are agreed upon as described above, the client and server exchange certificates using the selected public key cipher.
Encryption is a part of the task, but in particular, the sender is also concerned with validating the certificate of the receiver to ensure that no unauthorized receiver is enabled to receive the sender's e-mail communications.